Business Analyst Community & Resources | Modern Analyst

What are some of the benefits of a requirements management tool?

Emy — Fri, 29 Feb 2008 13:13:00 GMT

A requirements management tool supports the analyst in documenting project requirements, versioning requirements, managing the requirement change process, tracing requirements through the analysis and design process, and tracking the status of requirements.

Some examples of requirement management tools are:

Enterprise Architect,
Requisite Pro,
Telelogic,
Caliber-RM

And here is a more extensive list of top benefitsof a requirements management tool:

Management and tracking of requirements including traceability, versioning, auditing, history

Requirements workflow and approval

Colaborative requirements development, even when team members are remote

Automatic generation of requirement documents and specifications

Generation and traceability of test cases and test scenarios

Tools with graphical design options enable requirements to be represented as diagram and/or user interface mockups and prototypes

End-to-end impact analysis and coverage validation

What is a Requirements Traceability Matrix?

Emy — Thu, 24 Jan 2008 05:06:00 GMT

First of all, let’s talk about requirements traceability in general. Requirements traceability is the ability to follow and audit the life of a requirement, in both a forward and backward direction: from its origins, through its realization in the design and functional specifications, to its eventual development and deployment and use, and through subsequent rounds of modification and refinement.

A Requirements Traceability Matrix is just one method of performing and maintaining requirements traceability.

A good Requirements Traceability Matrix template or any other robust method for managing requirements traceability for a project can answer a variety of questions and solve numerous problems such as:

How was a specific requirement implemented?
What pieces of code will potentially be impacted by modifying a given requirement?
Which test cases are used to verify what requirements?
If I change a specific feature in the application what are the requirements which need to be looked at for impact?
What are all the places in the system where a given piece of data is being used?
etc.

--
Chris Adams
LinkedIn Profile

Are there scenarios where the developers will produce something different from your requirements spec, and how would you handle this?

Emy — Sun, 13 Jan 2008 15:46:00 GMT

Yes, there are instances when the developers will produce something different than what the requirements or functional specification documents contain. Here are some of the instances/causes of such differences:

The specifications are ambiguous or incomplete and they can be easily interpreted in multiple ways. In this case, the developer may have simply misinterpreted the ambiguous requirement in a different way than what was intended.
The developer simply ignored the specification and/or just read it quickly and then developed the system from memory.
The development team encountered technical limitations and the system cannot be developed exactly the way they were specified.

In general, the best way to handle this is to have a clear process in place to manage differences between the specification and the developed product. This would require a strong QA team and QA process. Here are some more detailed which address the three items above:

First and foremost, ensure that the business analysis team has documented guidelines for creating requirements and functional specifications as well as processes in place for peer and management review of analysis artifacts to ensure they are accurate and unambiguous. In addition, since the QA team is responsible for creating test cases and scenarios based on the requirements and functional specifications, they should look for, find, and document as spec defects (bugs) those areas of the analysis artifacts which are ambiguous or are missing information. These defect reports can be used by the analysis manager to identify areas of improvement and also to provide performance feedback to the individual business systems analyst.
Create a process in the development team for each developer to be accountable for his/her deliverables and produce code which is defect free. In addition, the QA team should be able to find these discrepancies and create defect reports (bugs) for the development team to fix.
A process should be in place to deal with instances when the requirements cannot be implemented as outlined in the functional specifications. Have the development team review the functional specs and provide feedback before the coding starts. The development team should be a key stakeholder and reviewer of the analysis artifacts. The feedback can then be incorporated back into the analysis artifacts and, hopefully, resulting in the alignment of the specifications and developed product.